[% setvar title Perl6 Summary for the week ending 20020728 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='Perl6 Summary for the week ending 20020728'></a><h1>Perl6 Summary for the week ending 20020728</h1>
<p>Better late than never, it's the return of Piers Cawley's Perl 6
summaries. First I'd like to thank the very lovely, and worthwhile
Leon Brocard for his excellent job of producing last week's
summary. Any suggestion that I only asked him to do the job because it
made the job of mentioning his name that much easier this week will be
laughed at.</p>
<a name='The Perl Conference'></a><h2>The Perl Conference</h2>
<p>Last week saw the 6th O'Reilly Perl Conference. I wasn't there and am
only slightly jealous. As well as producing parodies of the Apple
Switch ads and other amusing things, people talked about useful and
interesting stuff, including Perl 6 and Parrot. Sadly there are no
<code>switch/parrot</code> or <code>switch/perl6</code> spoof ads. Yet. However, Leon Brocard
has made the slides from his `Targeting Parrot' talk available. Leon
is particularly proud of the typography, apparently.</p>
<p><a href='http://astray.com/targeting_parrot/' target='_blank'>astray.com</a></p>
<p>Apart from the conference, most of the Perl 6 action has been in
perl6-internals, so we'll start there.</p>
<a name='Keyed Access'></a><h2>Keyed Access</h2>
<p>Scott Walters thought that &quot;Keys are not needed.&quot; and claimed that
they were a premature optimisation which should be done away with to
prevent ugliness. Dan pointed out that Scott had missed the important
case where data was inherently multi-dimensional. Josef
H&ouml;&ouml;k had a dream about morph chains and caching. Scott
pressed his case once more and Dan replied pointing out a few
misapprehensions on Scott's part and generally mounting a sturdy
defence of the status quo, which caused an outbreak of agreement and
general understanding. Scott patched up docs/vtables.pod to
incorporate the information in this thread. Yay Scott! He then
implemented multilevel key lookup for arrays. Double yay Scott!</p>
<p>Meanwhile, over in a side thread, Ashley Winters proposed
`ParrotTuple' as a possibly useful PMC, Leon Brocard concurred,
suggesting that, because it should be a relatively simple PMC to
implement it'd make a great learning project (and, potentially, a
great teaching project once it was implemented). Aldo Calpini and
Stephen Rawls both volunteered to have a crack at it.</p>
<p>Whilst we shouldn't poke fun, the suggestion that Parrot's opcode
dispatch takes 'non-finite time' did make me smile.</p>
<p>Dan promises a better spec for multi level keyed access as soon has
he finishes the TPC talk slides.</p>
<p>Quote of the thread: &quot;Generality and elegance are nice, but the point
is to go faster&quot; -- Dan Sugalski</p>
<a name='Hashing PMCs'></a><h2>Hashing PMCs</h2>
<p>Note: Piers Cawley is me. I'll stick to referring to myself in the
third person when discussing my posts to the mailing lists. Piers does
not do Cerebus the Aardvark imitations all the time.</p>
<p>Anyhoo, Alberto Manuel Brand&atilde;o Sim&otilde;es (who I will be
calling `Alberto' for the rest of the summary) made some
suggestions about the implementation of hashing of PMCs in Parrot. Dan
said that we should add an `id' method to the basic PMC vtable, and it
should return an INTVAL. Nicholas Clark suggested that maybe it'd be
better to return an unsigned value and Piers Cawley suggested that, if
we were going to call it `id' then it should return a guaranteed
globally unique value. Brent Dax suggested that, whatever it was
called it should return a string, giving <code>new
Math::BigFloat('3.1415926535897932384626433832795');</code> as his telling
example. Alberto reckoned that, if <code>@a = (1,2,3)</code> and <code>@b = (1,2,3)</code>
then <code>@a.hash == @b.hash</code> should hold. Piers disagreed and commented
that languages like scheme have two or three different
equality/equivalence operators to deal with this sort of thing. Dan
agreed with him.</p>
<a name='GC Speedup'></a><h2>GC Speedup</h2>
<p>Mike Lambert has committed some changes to Parrot's Garbage Collector
that give an 8% performance improvement on the GC heavy tests in
examples/benchmarks. Yay Mike! Peter Gibbs pointed out that we're
still a lot slower than pre 0.0.7 versions of Parrot. The delay
appears to have been introduced because of the `addition of stack-walk
code to avoid child collection', which is apparently required to
handle exceptions cleanly. Nicholas Clark wondered if we couldn't
avoid the stack-walk and get a speedup if we're not calling any
external code, but that would mean extra bookkeeping, which might slow
things down again. Mike Lambert thought Nick's scheme might have merit
and lamented the lack of `real world' parrot programs. But then, as he
pointed out, what <i>is</i> a `real world' program? Mike also reflected on
the mysteries and difficulties of tuning garbage collectors; the
controls available appear to be somewhat complex and the trade offs
are subtle and quick to anger. Mike is looking forward to tuning the
GC against parrot code that's generated by Sean O'Rourke's perl6
compiler.</p>
<a name='Regex bugfix and speedup'></a><h2>Regex bugfix and speedup</h2>
<p>Angel Faus has been working on the parrot regex engine and submitted a
patch that gives a substantial speedup with simple patterns. Nicholas
Clark wondered about compiling perl 5 with regex optimisations turned
off so we could compare the speeds of the basic engines without
magic. Simon Cozens reckoned that this would be a pointless
exercise. Nick restated his reasoning, and Simon then wondered if the
current parrot regex engine was worth comparing against, and if it was
well enough designed to cope with the rigours of Apocalypse 5 type
patterns. Hugo van der Sanden thought that turning off the optimiser
in perl 5 would not be easy, but he'd like to make it easier on the
perl 5.9 track.</p>
<a name='[PATCH] Reduce array.pmc keyed code'></a><h2>[PATCH] Reduce array.pmc keyed code</h2>
<p>Mike Lambert offered a patch to get rid of some of the clutter in
<code>array.pmc</code> and the resulting <code>array.c</code> by introducing a layer of
indirection, and asked for comments. Scott Walters pointed at his
earlier posts about refactoring the PMCs and suggested working
together on the issue. And there was agreement. Nicholas Clark added
his weight to this by pointing out that, in perl 6, being able to say
&quot;`this is an array of ints' and have them stored in sizeof(int)&quot; has
been blessed by Larry in one of the apocalypses.</p>
<a name='Meanwhile, in perl6-language'></a><h2>Meanwhile, in perl6-language</h2>
<p>Things were quiet, too quiet. The `Hashing PMCs' discussion took place
partially in perl6-language, with crossposts back to
perl6-internals. Otherwise not much was said.</p>
<p>David Nichol offered some cunning thoughts about perl in a distributed
persistent world which looked interesting, and offered a possible
macro definition syntax. Luke Palmer didn't like the syntax and
wondered if David wasn't thinking too much in Perl 5.</p>
<a name='In brief'></a><h2>In brief</h2>
<p>We're still assuming that the minimum version of perl you need to
build Parrot is 5.005, the eventual goal being to make the build self
supporting using a `miniparrot' approach (I wonder if we'll call that
`budgerigar' or `parakeet').</p>
<p>The mailing list archives are still not searchable (tell me about it),
but Brent Dax points out that the ever wonderful Google has the
<code>site:</code> keyword to do search restriction. I foresee a handy little
autobookmark appearing on my galeon toolbar real soon now.</p>
<p>Steve Fink suggested that <code>RECALL</code> wasn't that good a name for Tanton
Gibbs' proposed new preprocessor instruction because of the confusion
between `recall' and `re-call', proposing <code>REINVOKE</code>, <code>RE_CALL</code>,
<code>CHAIN</code> and the rather wonderful
<code>DOITOVERAGAINBUTDOITRIGHTTHISTIME()</code>. Brent Dax suggested <code>AGAIN</code>
(visions of the teletubbies as parrot programmers swam in at least one
head). This particular bikeshed has now been painted <code>AVOID</code>.</p>
<p>Sean O'Rourke thinks there's a problem with <code>find_method</code>. Nobody
else appears to have any thoughts. Warnock's Dilemma applies.</p>
<p>Aldo Calpini provided a short tutorial on submitting patches.</p>
<p>Simon Glover found a bug in parrot's file handling. Apparently the
<code>open</code> opcode disagrees with <code>read</code> and <code>write</code> (from core.ops)
about what a file handle should look like. Warnock's Dilemma applies.</p>
<p>Simon Cozens' head is exploding as he tries to make an inherently
recursive operation into an iterative one.</p>
<p>Jonathan Sillito had a couple of questions about lexical scopes and
scratchpads; apparently he has an implementation sketched out, but
wanted some clarification. Melvin Smith is also working on something
similar.</p>
<p>If you have a `Parrot' directory in your copy of the parrot source,
you should probably get rid of it; it can be hard to make diffs
otherwise, as Tanton Gibbs discovered.</p>
<p>Stephen Rawls has a problem; Spamassassin thinks his patches are
spam.</p>
<p>Miguel de Icaza of Ximian popped up, via Simon Cozens, to point out
that the mops test for C# wasn't quite comparing apples with apples
because it was using 64 bit values and everything else was using 32
bit integers. Melvin Smith fixed it.</p>
<p>Brent Dax is on holiday 'til August the 3rd. Melvin Smith is supposed
to be using the time to spread rumours about him and generally running
amok through Brent's code. But he hasn't spread any rumours about
Brent yet, though I heard that Brent's `holiday' was in fact a trip
back to the factory for an oil change and to have his nuts tightened.</p>
<p>Melvin Smith things Array.pmc is broken and is going to apply some
PerlArray.pmc fixes back to Array.pmc. Sean pointed out that there's
some perl specific behaviour in PerlArray.pmc that shouldn't be
ported.</p>
<p>Mike Lambert, bless him, asked if he could propose a `simply-phrased
question?'. He had an IntArray in @P1 and a NumArray in @P2 how would
he do the equivalent of <code>S1 = P1[5] * P2[5]</code>? He reckons the answer
is trickier than it looks.</p>
<p>Sean O'Rourke wants more ops. As things stand there's no way to get to
the vtable's cmp_num and cmp_string methods from parrot
assembly. Which is bad. He offers a patch.</p>
<a name='Patches'></a><h2>Patches</h2>
<p>St&eacute;phane Payrard wanted to play with Qt from parrot, but the
sources didn't play well with C++. So he's offered a patch.</p>
<p>Alberto has some docs about various PMCs available at
<a href='http://natura.di.uminho.pt/~albie/parrot/.' target='_blank'>natura.di.uminho.pt</a></p>
<p>Alberto also offered a Boolean.pmc, but it wasn't accepted. However,
it's nice, simple example of PMC implementation that may well repay a
closer look if you're interested in that sort of thing.</p>
<p>Johnathan Sillito implemented an `invoke' op which calls an arbitrary
vtable method. Applied.</p>
<p>Angel Faus offered a patch which `apparently makes the rx engine
behave well with the GC'. Warnock's Dilemma applies.</p>
<p>The <code>usleep</code> portability I mentioned in my last summary appears to
have been solved, but the patch hasn't been applied yet.</p>
<p>Andy Dougherty supplied a patch to eliminate 69 compilation
warnings. Applied.</p>
<p>Sean O'Rourke has patched the perl6 compiler to work with perl
5.005_03.</p>
<a name='Who's who in Perl6'></a><h2>Who's who in Perl6</h2>
<ul>
<li><a name='Who are you?'></a>Who are you?</li>
<p>Luke Palmer</p>
<li><a name='What do you do for/with Perl 6?'></a>What do you do for/with Perl 6?</li>
<p>I mainly discuss language design issues like the rest of the
second-level folk. I occasionally answer questions about Perl 6
syntax, as I have been following very closely it's creation.</p>
<li><a name='Where are you coming from?'></a>Where are you coming from?</li>
<p>Naturally, from a pathologically eclectic state of mind.</p>
<li><a name='When do you think Perl 6 will be released?'></a>When do you think Perl 6 will be released?</li>
<p>I don't really care, because I will surely be long deceased before
then. :)</p>
<li><a name='Why are you doing this?'></a>Why are you doing this?</li>
<p>Because I love programming, I love Perl, and I love community
projects.</p>
<li><a name='You have 5 words. Describe yourself.'></a>You have 5 words. Describe yourself.</li>
<p>My slogan: Luke smokes Perl.</p>
<li><a name='Do you have anything to declare?'></a>Do you have anything to declare?</li>
<p>Ha! Declarations are for structured programmers!</p>
</ul>
<a name='Acknowledgement, apologies and stuff'></a><h1>Acknowledgement, apologies and stuff</h1>
<p>There are a few things different about this week's Perl 6 summary.</p>
<ul>
<li><a name='1 It's late.'></a>1 It's late.</li>
<li><a name='2 There's no/very few links and URLs'></a>2 There's no/very few links and URLs</li>
<li><a name='3 Did I mention that it's late?'></a>3 Did I mention that it's late?</li>
<li><a name='4 The grammar's probably even ropier than usual'></a>4 The grammar's probably even ropier than usual</li>
</ul>
<p>Yes. I know. Last week was 'fun', for highly sarcastic values of
fun. Hopefully net access, commute times and general time available to
write summaries will be back to normal next week and you'll get a
lovely, shiny, highly linked summary. I'm publishing this now --
without my usual level of proof reading -- only because I'm running so
damned late.</p>
<p>Actually, feedback on this would be good; in general adding the links
is the most time consuming and tedious part of writing the summaries,
requiring a net connection and time to check the links. Which leads me
to wonder if I can't write links as predictable google searches using
the message-id. Time to experiment methinks.</p>
<p>As usual, if you liked the summary, send money to the perl foundation
to help support the ongoing development of Perl 6. Or you could send
me one of those shiny T?iBooks that all the cool kids were playing
with at TPC. But that's just naked self interest on my part and I'm
really writing summaries for love, kudos and egoboo.</p>
<p>Also, if you're involved, however peripherally in the Perl 6
development process, I'd really appreciate it if you'd answer the
<a href='http://archive.develooper.com/perl6-internals@perl.org/msg10797.html' target='_blank'>archive.develooper.com</a>
I posted. I'm still waiting for answers from Larry and Damian; Dan's
answers will be forthcoming in 5 week's time (I'm publishing them in
strict order of receipt).</p>
</div>
